はじめてのAWS Snowcone – (7) EC2のセットアップ
しばたです。
本記事ではSnowconeデバイスでEC2インスタンスを利用する方法について解説します。
目次
- はじめてのAWS Snowcone - (1) はじめに
- はじめてのAWS Snowcone - (2) 事前準備から注文まで
- はじめてのAWS Snowcone - (3) AWS OpsHub for Snow Family のインストール
- はじめてのAWS Snowcone - (4) デバイスの配送から受け取りまで
- はじめてのAWS Snowcone - (5) ネットワーク設定とロック解除
- はじめてのAWS Snowcone - (6) NFSサーバーのセットアップ
- はじめてのAWS Snowcone - (7) EC2のセットアップ
- はじめてのAWS Snowcone - (8) AWS DataSync Agentのセットアップ
- はじめてのAWS Snowcone - (9) その他機能、デバイスの停止
- はじめてのAWS Snowcone - (10) CLIでSnowconeデバイスを操作する
- はじめてのAWS Snowcone - (11) デバイスの返却からS3インポートまで
- はじめてのAWS Snowcone - (12) Snowconeジョブの物流と請求について
免責事項
EC2のセットアップ
今回はAWS OpsHubを使いEC2の各種設定を行います。
AWS OpsHubのインストールとデバイスの初期設定については以下の記事を参考にしてください。
以降の作業はAWS OpsHubにサインインした状態からはじめます。
1. コンピューティングの開始
OpsHubではEC2関連の設定は「コンピューティング」としてまとめられています。
デバイス詳細画面の「コンピューティングを開始」欄を選び「使用開始」をクリックします。
するとコンピューティングの画面に遷移し、ここでEC2インスタンスの管理を行うことができます。
ざっくり「 セキュリティグループの無いEC2マネジメントコンソール 」だと思って頂ければ雰囲気は伝わると思います。
いちおう補足しておくと正確には「default」セキュリティグループが存在するのですがSnowconeにおいては全く使いません。セキュリティグループは無いものと考えて大丈夫です。
インスタンス一覧の他に、ストレージボリューム一覧やキーペアの一覧も参照できます。
2. キーペアの作成
通常のEC2と同じ様にSnowconeでもEC2キーペアを作成することができます。
キーペアタブにある「キーペアを作成」をクリックするとキーペアを作れます。
作成と同時に公開鍵をダウンロードできます。
ちなみに鍵はPEM形式です。
3. EC2インスタンスの作成
次にEC2インスタンスを作成します。
インスタンスタブにある「インスタンスを起動」をクリックすると作成ダイアログが表示されるので必要な情報をよしなに設定します。
AMIはジョブの作成時に指定したものから選択可能です。
まずは標準で用意されているAmazon Linux 2イメージを選んでいます。
インスタンスタイプは以前解説した様に以下の3種から選択可能です。
インスタンスタイプ | vCPU | Memory | 同等タイプ | 備考 |
---|---|---|---|---|
snc1.micro | 1 | 1GB | t2.micro | 最大2インスタンス |
snc1.small | 1 | 2GB | t2.small | 最大2インスタンス |
snc1.medium | 2 | 4GB | t2.medium | 最大1インスタンス |
ネットワーク設定については物理NICの配下に仮想NIC(VNI)を作る形となります。
こちらは環境に応じてIPアドレスを設定してください。今回は静的にIPを割り当てています。
キーペアは前節で作成したものを選びます。
このダイアログから作成することもできますし、AMI作成時にパスワード認証を有効にしているのであればキーなしのインスタンスも作成可能です。
最後に「起動」をクリックするとインスタンスの作成が開始されます。
しばらく待つとインスタンスの状態が「実行中」にかわり利用可能になります。
インスタンスの詳細はこんな感じです。
ストレージボリュームはこんな感じでルートボリュームが増えています。
ちなみに別途ストレージボリュームを追加してEC2に増設(追加アタッチ)することも可能です。
とりあえずEBSの規則に合わせる形でデバイス名は/dev/sdf
にしましたが、アタッチされたOS内部からは準仮想化ディスク(/dev/vda
)として見える様です。
# 追加ディスクをアタッチしたOS内部でのコマンド実行結果
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 8G 0 disk
tqsda1 8:1 0 8G 0 part /
mqsda128 259:0 0 1M 0 part
vda 252:0 0 100G 0 disk
「Amazon S3 へのインポート」ジョブの場合EC2が利用可能なストレージの総量は約150GB(157970247680Byte)のみです。
同梱したAMIのサイズは含まれていませんでした。
今回は確認できませんが「ローカルコンピューティングとストレージのみ」ジョブの場合はここが8TBになるのだと予想されます。
EC2インスタンスを試してみる
作成したEC2インスタンスへはSSHでアクセスします。
基本的には前節で作成したキーペアを使った鍵認証をすればOKです。
あとは通常のEC2と同じ様に扱えます。
ちなみにeth0
が34.223.14.128/25
なネットワークにある形になっていました。
これがSnowcone内部ネットワーク[1] でVNIへNATしている様です。
1. インスタンスメタデータへのアクセス
EC2からインスタンスメタデータへのアクセスも可能でした。
ざっくり以下の様な結果でした。
# インスタンスメタデータ(v1) が利用可能
$ curl http://169.254.169.254/latest/meta-data/
ami-id
hostname
instance-id
instance-type
local-hostname
local-ipv4
mac
network/
reservation-id
security-groups
public-ipv4
# インスタンス情報は特筆する点なし
$ curl http://169.254.169.254/latest/meta-data/ami-id
s.ami-0e96d810764e93bd4
$ curl http://169.254.169.254/latest/meta-data/instance-id
s.i-811bef5f04eb1a609
$ curl http://169.254.169.254/latest/meta-data/instance-type
snc1.micro
# Private IPが 34.223.14.128/25 で Public IPがVNIのIPに見える形となる
$ curl http://169.254.169.254/latest/meta-data/local-ipv4
34.223.14.193
$ curl http://169.254.169.254/latest/meta-data/public-ipv4
192.168.9.156
# セキュリティグループは default
$ curl http://169.254.169.254/latest/meta-data/security-groups
default
SnowconeのEC2からはVNIのIPがPublic IPとして見え、現実のGlobal IPとLocal IPが逆転している様になっているのは面白いです。(やっぱりNATしてますね。これは。)
2. EC2からNFSサーバーへのアクセス
EC2からNFSサーバーへのアクセスも可能です。
特別な内部ルートなどは無い様で普通にVNI経由でアクセスします。
# ネットワーク経由でNFSサーバーにアクセス可能
sudo mkdir /mnt/nfs
sudo mount -t nfs 192.168.9.155:buckets/shibata-snowcone-test-2021 /mnt/nfs
マウントした結果はこんな感じ。
# NFSサーバーへばっちりアクセス可能
$ ls -al /mnt/nfs/
total 12492
drwxrwxrwx 1 root root 68 Dec 25 00:50 .
drwxr-xr-x 3 root root 17 Dec 25 04:54 ..
-rwxr-xr-x 1 4294967294 4294967294 12788163 Dec 25 00:46 100000-files.zip
drwxr-xr-x 1 4294967294 4294967294 386 Dec 25 01:01 bigfiles
drwxr-xr-x 1 4294967294 4294967294 3400000 Dec 24 21:56 smallfiles
3. 同梱したAMIについて
今回は標準で提供されるAmazon Linux 2イメージの他に
- 自分で用意したカスタムAmazon Linux 2 AMI
- CentOS 7 AMI
- Ubuntu 16.04 AMI
を用意しました。
それぞれを試した結果を以下に記載します。
3-1. カスタムAmazon Linux 2 AMI
原因は調査中ですがこのAMIだとEC2は起動したものの一切接続できない+Pingも通らない状態になりました。
標準で提供されるAMIと区別するためにEBSをgp3にしてたのでですが、おそらくこれが悪かったんだと思います。
(他のAMIは全部gp2で作っており問題なく利用できたため)
3-2. CentOS 7 AMI
特に問題なく利用できました。
3-3. Ubuntu 16.04 AMI
Snowconeで用意したキーペアが使えずAMI作成時のキーペアでログインし利用することができました。
詳しく調べていませんがおそらくcloud-initのどこかでエラーになってるんだと予想しています。
Snowconeデバイスのリソース制限
Snowconeデバイスではコンピューティングに利用可能なリソース上限が決められており、上限を超える様にEC2インスタンスを作成した場合はエラーとなります。
インスタンスの起動に失敗しました: Snowball has insufficient capacity to launch the instance in this request.
リソース上限についてはAWS OpsHubから確認できないものの、Snowball Edge Client(snowballEdge
コマンド)から確認することができます。
# PowerShell 7.2.1環境で実施 (他シェルではjqなどで頑張ってください)
C:\> snowballEdge describe-device --profile my-first-snowcone | ConvertFrom-Json | Select-Object -ExpandProperty DeviceCapacities
Name : HDD Storage
Unit : Byte
Total : 157980389376
Used : 10737418240
Available : 147242971136
Name : SSD Storage
Unit : Byte
Total : 0
Used : 0
Available : 0
Name : vCPU
Unit : Number
Total : 3
Used : 2
Available : 1
Name : Memory
Unit : Byte
Total : 5368709120
Used : 2147483648
Available : 3221225472
Name : GPU
Unit : Number
Total : 0
Used : 0
Available : 0
コマンドの結果について細かい解説はしませんが、vCPUの上限が3、メモリの上限が5GBとなっておりSnowconeのデバイス仕様(2vCPU、4GBメモリ)に対しPreload NFS Client(1vCPU、1GBメモリ)の分が上乗せされている[2]のが面白いですね。
これにより
- Preload NFS Client + EC2インスタンス(snc1.small) x 2
- Preload NFS Client + Preload DataSync Client
の組み合わせも可能であると見て取れます。
なお、リソースはEC2の状態(起動・停止)によらずEC2を作成した時点で消費されます。
Snowconeのネットワーク構成
最後にSnowconeのネットワーク構成について軽く解説します。
Snowconeのネットワーク構成はLAN1、LAN2の物理NICに加え、各物理NICと紐づく形となる仮想NIC(VNI)を各サービスで利用する形となります。
まあ、これはENIの様なものだと思っていただくのが手っ取り早いでしょう。
VNIだけでなく物理NICと直接マッピングするダイレクトNIC(DNI)も定義可能です。
DNIではMACアドレスのカスタマイズやVLANタグがサポートされているそうです。
こちらはAWS OpsHubからは作成できずCLIを使う必要があります。
それぞれの詳細は以下のドキュメントをご覧ください。
加えて先述の通りSnowcone内部には34.223.14.128/25
なネットワークが存在しており、内部ネットワークにあるEC2は相互に通信可能です。
補足1 : NFSサーバーの内部IPアドレス
NFSサーバーもVNIを使っている以上おそらく内部ネットワークに実体となるインスタンスがあるものと予想されます。
ただNFSサーバーの内部IPを知る方法が一切無いため、結局はVNI経由でアクセスするしかありませんでした。
補足2 : DNIの作成例
細かい解説まではしませんがDNIを作成する例を以下に記載します。
まずはCLIでDNIを作成します。
以下の例ではLAN2(RJ45_2
: s.ni-88cabc27426d3c6e7
)とEC2インスタンス(s.i-811bef5f04eb1a609
)をマッピングしています。
# PowerShell 7.2.1環境でSnowball Edge Clientを使用
# 物理NICのIDを取得 (この例ではLAN2を使う)
C:\> snowballEdge describe-device --profile my-first-snowcone | ConvertFrom-Json | Select-Object -ExpandProperty PhysicalNetworkInterfaces
PhysicalNetworkInterfaceId : s.ni-842025a469b4329e5
PhysicalConnectorType : RJ45
IpAddressAssignment : STATIC
IpAddress : 192.168.9.150
Netmask : 255.255.255.0
DefaultGateway : 192.168.9.1
MacAddress : 8c:0f:6f:xx:xx:xx
PhysicalNetworkInterfaceId : s.ni-88cabc27426d3c6e7
PhysicalConnectorType : RJ45_2
IpAddressAssignment : STATIC
IpAddress : 192.168.9.160
Netmask : 255.255.255.0
DefaultGateway : 192.168.9.1
MacAddress : 8c:0f:6f:xx:xx:xx
# DNIを作成 (最低限の設定のみ)
C:\> snowballEdge create-direct-network-interface --profile my-first-snowcone `
--instance-id 's.i-811bef5f04eb1a609' `
--physical-network-interface-id 's.ni-88cabc27426d3c6e7'
{
"DirectNetworkInterface" : {
"DirectNetworkInterfaceArn" : "arn:aws:snowball-device:::interface/s.ni-85371eea7a3dd2a51",
"PhysicalNetworkInterfaceId" : "s.ni-88cabc27426d3c6e7",
"InstanceId" : "s.i-811bef5f04eb1a609",
"Driver" : "ixgbevf",
"MacAddress" : "1a:74:cc:18:d4:b6"
}
}
# DNIの確認は snowballEdge describe-direct-network-interfaces コマンドを使う
C:\> snowballEdge describe-direct-network-interfaces --profile my-first-snowcone
{
"DirectNetworkInterfaces" : [ {
"DirectNetworkInterfaceArn" : "arn:aws:snowball-device:::interface/s.ni-85371eea7a3dd2a51",
"PhysicalNetworkInterfaceId" : "s.ni-88cabc27426d3c6e7",
"InstanceId" : "s.i-811bef5f04eb1a609",
"Driver" : "ixgbevf",
"MacAddress" : "1a:74:cc:18:d4:b6"
} ]
}
この時点で当該インスタンスには新しいNIC(通常であればeth1
)が生える形となります。
NICが生えたもののまだ未設定の状態ですのでドキュメントあるサンプルをベースにNICの設定をしてやります。
# ドキュメントのサンプルを一部変更しAmazon Linux 2インスタンスで実施
# * https://docs.aws.amazon.com/snowball/latest/snowcone-guide/snowcone-network-config-ec2.html
# DNIのMACアドレスを設定
DNI_MAC=1a:74:cc:18:d4:b6
# DNIのNIC名を設定。通常は eth1 。
DNI=eth1
# EC2のVNI (通常eth0) の情報を取得し、内部ネットワークの通信はeth0経由になる様にルーティングテーブルを更新
PRIVATE_IP=$(curl -s http:/169.254.169.254/latest/meta-data/local-ipv4)
PRIVATE_GATEWAY=$(ip route show to match 0/0 dev eth0 | awk '{print $3}')
ROUTE_TABLE=10001
echo from $PRIVATE_IP table $ROUTE_TABLE | sudo tee -a /etc/sysconfig/network-scripts/rule-eth0
echo default via $PRIVATE_GATEWAY dev eth0 table $ROUTE_TABLE | sudo tee -a /etc/sysconfig/network-scripts/route-eth0
# DNI (eth1) の設定ファイルを追加 : この例では DHCP だが環境にあわせてよしなに変更可能
cat << EOF | sudo tee -a /etc/sysconfig/network-scripts/ifcfg-$DNI
DEVICE="$DNI"
NAME="$DNI"
HWADDR="$DNI_MAC"
ONBOOT=yes
NOZEROCONF=yes
BOOTPROTO=dhcp
TYPE=Ethernet
EOF
## 必要があればデバイス名を変更する、とのことだったが今回は実施せず。 : 変更する必要がなかったため
# Rename DNI device if needed.
# CURRENT_DEVICE_NAME=$(LANG=C ip -o link | awk -F ': ' -vIGNORECASE=1 '!/link\/ieee802\.11/ && /'"$DNI_MAC"'/ { print $2 }')
# ip link set $CURRENT_DEVICE_NAME name $DNI
# Networkサービスの再起動
sudo systemctl restart network
結果LAN2を使用するeth1
に192.168.9.159 (DHCP)
が割り当たり利用可能になります。
ちなみにeth0
はLAN1を使うVNIであり物理NICをまたぐ形になっているのですが、この様な構成も可能です。
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 52:54:00:ce:2e:d4 brd ff:ff:ff:ff:ff:ff
inet 34.223.14.193/25 brd 34.223.14.255 scope global dynamic eth0
valid_lft 3581sec preferred_lft 3581sec
inet6 fe80::5054:ff:fece:2ed4/64 scope link
valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 1a:74:cc:18:d4:b6 brd ff:ff:ff:ff:ff:ff
inet 192.168.9.159/24 brd 192.168.9.255 scope global dynamic eth1
valid_lft 259184sec preferred_lft 259184sec
inet6 fe80::1874:ccff:fe18:d4b6/64 scope link
valid_lft forever preferred_lft forever
最後にDNIを削除する場合はsnowballEdge delete-direct-network-interface
コマンドを使います。
(当然ですが事前にEC2側の設定を元に戻してください)
# DNIを削除
C:\> snowballEdge delete-direct-network-interface --profile my-first-snowcone --direct-network-interface-arn "arn:aws:snowball-device:::interface/s.ni-85371eea7a3dd2a51"
The direct network interface has been deleted from your Snowball Edge. You can determine the direct network interfaces available on your Snowball Edge using the describe-direct-network-interfaces command.
終わりに
今回はここまでです。
つぎはPreload DataSync Agentを試す予定です。